home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 559 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.9 KB
  1. From: itschere@techfak.uni-bielefeld.de
  2. Subject: Re: pipes & ptys
  3. Date: Tue, 19 Oct 93 14:43:48 MET
  4.  
  5. Howard Chu <hyc@hanauma.jpl.nasa.gov> writes:
  6.  
  7. > A simple shell would just use cooked mode and read a line at a time, not
  8. > single-character, btw...
  9.  
  10. Maybe the shell, but not my imaginary window manager. If it waits for each
  11. newline, screen output will look pretty poor... :-(
  12.  
  13. > Just a note to TeSche - the 1 byte I/Os are converted to 4 bytes to allow
  14. > pty's to pass scan code and shift status info, just like Bconin from console.
  15.  
  16. Looking at the code, I discovered that recently. Point is that it - more or
  17. less - doesn't matter if my 1000 1 byte fread calls get expanded to 100 4 bytes
  18. fread calls. It looks like waiting with fselect(m,0,0,0) (thanks Eric!) and
  19. than read all that is there with one fread call is the best idea at the
  20. moment. I'll look at it, but for now I presume finstat() really reports the
  21. number of bytes in a pipe. So at least my reading program will not be the
  22. bottleneck, if the writing one choses to write in 1 byte chunks, I loose...
  23.  
  24. > I kind of like it. The main point being, we want a system call that actually
  25. > reads or writes more than 1 byte at a time for ttys. So doing an Fread of 1K
  26. > on /dev/modem1 does a single call, not 1000 Bconin's... I would like to see
  27. > these new read and write functions replace Bconin/Bconout, with Bcon* just
  28. > being a special-case (single-character) of them.
  29.  
  30. Looks like this is what I _really_ wanted to say... :-)
  31.  
  32. But what we _really_ want is a extra device driver for each modem device that
  33. outputs/reads characters driven by interrupt, so the whole Bcon*() stuff gets
  34. obsolete. So you won't need an extra system call, but just a new device
  35. driver for the biosfs...
  36.  
  37. Perhaps I'll start playing with this idea in some future, it's just that I
  38. expect great difficulties with existing programs, since they MUSTN'T use the
  39. bcon*() calls any more... :-(
  40.  
  41. bye,
  42. TeSche
  43.  
  44.